Setting

View Active Alerts

This window displays all the active alerts generated. The details displayed here are – alert severity, acknowledge, rule name, alert message, alert time, time ago the alert was generated, subject, and alert value. You can view active alerts (the alerts which are currently in an active state) via the Settings button  and by selecting the Active Alert option.

Figure 29: Active Alerts

Note: All the active alerts are displayed in the Alerts window.

Figure 30: Active Alerts Window

Note: In the Acknowledge section, all the alerts which are active and not yet acknowledged by the user will blink with a Red Dot  .

View Alert History

Alert history is useful in obtaining insights into past-generated alerts. Alert history is also used to understand how the severity of specific alerts may have changed over a period of time.

You can view alert history (the alerts which are currently not in an active state) via the Settings button  and by selecting the Alert History option.

Figure 31: Alert History

This displays the Alert History.

Figure 32: Alert History Page

Alert Rules

The Alert rule is the key element where you can define the metric and associated thresholds to generate an alert for a specific severity. To view the alert rules, click the Rules List    button on the Alert window. This displays the Alert Rules window.

Figure 33: Alert Rule Window

The following details are displayed:

  • Status: Represents whether the Rule is enabled/disabled.
  • Rule Name: Name of the rule.
  • Condition Expression: Displays the summarized view of the conditions. On mouse hover, the detailed condition is displayed.
  • Alert Message: Message to be displayed when an alert is encountered.
  • Alert Action: To notify users of this alert.

You can perform the following operations:

  • Configure the alert rule by clicking the Add Rule button.
  • Refresh all the alert rules by clicking the button.
  • Copy the selected alert rules by clicking the button.
  • Enable the selected alert rules by using the Toggle button .
  • Disable the selected alert rules by clicking the button. 
  • Delete the selected alert rules by clicking the button.
  • Download the selected alert rules by clicking the button.
  • Import the selected alert rules by clicking the button.
  • Export the selected alert rules by clicking the button.
  • Apply column filters by clicking the button.
  • View/hide columns by using the icon.
  • Edit an alert rule by clicking the button in the Actions section.

Configure Alert Rules

To configure alert rules, click the Add Rule  button on the Alert Rule window.

Figure 34: Add Rule Icon

This displays the Alert Rule Configuration window where you can configure rules for the alerts. This window is divided into various sections. The inputs required in each section are mentioned in the subsequent topics.

Figure 35: Alert Rule Configuration Window

Rule Information

Figure 36: Rule Information Window

Rule Type

  • Simple: Alert configurations are done for a single metric for critical, major, and minor thresholds. You can add a single condition only. You can provide the recovery threshold value for critical, major, and minor thresholds.
  • Composite: Configurations are done for multiple metrics for critical, major, and minor thresholds in separate sections. You can add multiple conditions by using the AND (&&) and OR (||) operators. You can provide the recovery threshold value for critical, major, and minor thresholds in their respective sections. Composite Rule lets you combine two or more separate rules using logical operators to further refine your alerts. Here, you can configure alerts for multiple metrics and set threshold for multiple severities (critical, major, and minor) in separate sections and combine those by using the logical operators, such as AND (&&) and OR (||), etc.

 

Select Metric Expression

Here, you can specify the metric expression on which the alert rule is to be applied. There are various inputs to select to specify the metric expression.

Figure 37: Select Metric Window
  • Metric Group: Metric group contains the metrics to which an event is to be applied. It is used to filter out the metrics.
  • Metric Name: Metric name belonging to the selected metric group.
  • Metric Attribute: Metric attribute (data type) of the selected metric, such as Avg/Min/ Max/Count on which the alert is to be configured.
  • Select Subjects: Subject is a hierarchy from which we get information about Tier, server, and instance. Based on the subject, data is pulled from the system for a particular metric. You can either select all or specify a subject.
  • : To view the graphs of the selected subject in the Dashboard.
  • : To delete the added metrics for the rule configuration. 
  • Generate Alert On: Generation of event based on the metrics level
    • Individual Subject Level: To generate events for every subject.

Example: If the Metric Group is SysStats Linux Extended, Metric Name is CPU Utilization (Pct), and Specified Subjects are AppTier>QAServer3, AppTier>QAServer4, then the events are generated at the individual level i.e. for AppTier>QAServer3 and AppTier>QAServer4.  

  • Group Level: To generate alerts based on the subject level – Tier/Server/Instance/ Business Transaction. If the Metric Group is SysStats Linux Extended, Metric Name is CPU Utilization (Pct), and Specified Subjects are AppTier>QAServer3, AppTier>QAServer4, then the events are generated at group level i.e. for AppTier.

Set Alert Condition

Next, you can set the alert condition(s) based on the rule type. The alert is triggered when the specified condition is met.

Figure 38: Alert Condition Window

Note: Recovery thresholds are optional thresholds added to alert conditions (Critical/ Major/Minor) to indicate an additional condition to metrics recovery from alert to normal states.

Example: If the critical threshold value is defined as 100 and the recovery threshold is defined as 50, then the recovery threshold is satisfied when the metric value is reached 50.

Condition Type

Condition Type-Threshold: This is a standard alert in which the expected values are known. A threshold alert compares metric values to a static threshold. It calculates the average/minimum/maximum/sum throughout the given period for each alert evaluation and verifies if it is above or below the threshold as shown in Figure Rule Information Window.

Figure 39: Set Alert Condition
  • Advanced option:
  • Rolling Interval: Graph data value for the alert is calculated on each new sample generated. For example: Suppose the rolling interval is defined as 1 minute and the window size is 5 minutes, then the first data samples are calculated for a 1-5 minutes window. Then, the second data samples are calculated for a 2-6 minutes window and similarly a third data sample for a 3–7-minute window, and so on.
  • Fixed Interval: Graph data value for the alert is calculated for a fixed time as specified. For example: Suppose the fixed interval is defined as 1 minute and the window size is 5 minutes, then the first data samples are calculated for a 1-5 minutes window. Then, the second data samples are calculated for a 6-10 minutes window and similarly a third data sample for a 11–15 minute window, and so on.
  • Check the condition at every one minute over rolling “X” intervals.
  • Check the condition at every “X” interval over a fixed “X” interval.
  • Trigger when every value of the metric during the last “X” minutes is above the threshold.
  • Advanced option:
    • Evaluate the value of the metric during the last “X” minutes using the last/any “Y” % samples.
    • Check the condition at every one minute over rolling “X” intervals.
    • Check the condition at every “X” interval over a fixed “X” interval.

Condition Type- Change: This type of alert is suitable when you need to find spikes, dips, or minor changes in a metric when the threshold is unexpected. A change alert matches the absolute or relative (percentage) change in value from X minutes to a set threshold. The compared data points are not single points but are calculated using the alert parameters in the alert conditions section as shown in as shown in figure.

Figure 40: Change Condition

On the assessment of each alert, the raw difference between the series now and X minutes ago is calculated, and then the average/minimum/maximum/sum over the selected period is computed. When this computed series crosses the threshold, an alert is triggered.

Trigger when to change/%change in average/sum of every/maximum/minimum/at least one value of the metric during the last “X” interval is above/above or equal to/below/below or equal to the threshold compared to an average of all samples during same time interval “Y” interval before.

  • Advanced option:
    • Check the condition at every one minute over rolling “X” intervals.
    • Check the condition at every “X” interval over a fixed “X” interval.

Trigger when to change/%change in every value of the metric during the last “X” interval is above/above or equal to/below/below or equal to the threshold compared to an average of all samples during the same time “Y” interval before.

  • Advanced option:
    • Evaluate the value of the metric during the last “X” minutes using the last/any “Z” % samples.
    • Check the condition at every one minute over rolling “X” intervals.
    • Check the condition at every “X” interval over a fixed “X” interval.

Condition Type- Anomaly: An anomaly detection alert uses the previous performance of a metric to spot when it is behaving unusually. Anomaly alerts analyze an estimated range of values for a series based on the previous time. Some anomaly algorithms calculate the expected range based on the time of day or a day of the week, identifying anomalies that would be missed by a basic threshold alert. For instance, the series is extremely high for 8 AM, despite being normal for 11 AM.

The percentage of the series that falls above, below, or outside of the expected range is determined for each alert evaluation. When this percentage crosses the preset threshold, an alert is triggered.

Figure 41: Condition Type- Anomaly

Trigger when at least one value of the metric during the last “X” interval is above/below/above or below the bounds.

  • Advanced option:
    • Check the condition at every one minute over rolling “X” intervals.
    • Check the condition at every “X” interval over a fixed “X” interval.
    • Severity: Critical/Major/Minor (default is Major)
    • Use theta/basic/agile/robust algorithm to detect anomalies “N” deviations from the predicted data.
      • Theta: Theta* is an any-angle path planning algorithm that is based on the A* search algorithm. With run times similar to those of A*, it can locate almost optimal pathways.
      • Basic: This is used when metrics have no recurring seasonal pattern. It uses a simple computation method to determine the range of predictable values. It consumes lesser data and regulates rapidly to changing conditions but has no understating of seasonal behavior or extensive trends.
      • Agile: This is used when metrics are seasonal and predicted to change. It rapidly regulates metric level shifts. It integrates the instant past into its forecast, allowing rapid updates for level shifts at the overhead of being less strong to recent, permanent anomalies.
      • Robust: This is used when seasonal metrics are predicted to be steady, and slow, level shifts are considered anomalies. It is very steady and predictions remain constant even through permanent anomalies at the expense of taking longer to respond to intended level shifts (For example: Shifting of a metric level due to code change).

Triggers when every value of the metric during the last “X” interval is above/below/above or below the bounds.

  • Advanced option:
    • Evaluate the value of the metric during the last “X” minutes using the last/any “Z” % samples.
    • Check the condition at every one minute over rolling “X” intervals.
    • Check the condition at every “X” interval over a fixed “X” interval
    • Severity: Critical / Major / Minor (default is Major)
    • Use theta/basic/agile/robust algorithm to detect anomalies “N” deviations from the predicted data.
  • Condition Type-Outlier: Outlier monitors detect when a subject of a group is behaving unusually compared to the rest of the subjects during a specified time period. On the assessment of each alert, it is analyzed whether or not all groups are grouped and showing the same behavior. When one or more groups deviate from the rest, an alert is triggered. You can use an algorithm (from the list) with a tolerance value.
Figure 42: Outlier

Triggers when at least one value of the metric for a subject is an outlier during the last “X” interval out of subjects at the same hierarchy.

  • Advanced option:
    • Check the condition at every “X” interval over a fixed “X” interval.
    • Use MAD/DBSCAN/ScaledMAD/ScaledDBSCAN algorithm with tolerance

0.33/0.5/1.0/1.5/2.0/2.5/3.0/3.5/4.0/4.5/5.0

Triggers when every value of the metric for a subject is an outlier during the last “X” interval out of subjects in the same hierarchy.

  • Advanced option:
    • Evaluate the value of the metric during the last “X” minutes using the last/any “Z” % samples.
    • Check the condition at every “X” interval over a fixed “X” interval.
    • Use MAD/DBSCAN/ScaledMAD/ScaledDBSCAN algorithm with tolerance

0.33/0.5/1.0/1.5/2.0/2.5/3.0/3.5/4.0/4.5/5.0.

  • MAD: The Median Absolute Deviation (MAD) is a strong measure of inconsistency, and can be observed as the robust equivalent of standard deviation. Robust statistics define information in such a way that outliers do not excessively affect them.
  • DBSCAN: It is a popular density-based clustering algorithm. It works by collecting or forming points into a mass or group that is close to each other. Clusters with few points in them are considered outliers.
  • ScaledMAD: The ScaledMAD algorithm considers the relative scales of the deviation and the median of the data. Mostly, it acts like the MAD algorithm. Though, when the scattering of the data set contracts as compared to the median, the space threshold for defining whether a point is an outlier becomes a part of the median.
  • ScaledDBSCAN: This algorithm scales the preliminary space threshold according to the relative magnitudes of the median series and the subjects’ distances to the median series. Mostly, it acts like a normal DBSCAN. However, when the median series is huge compared to the spaces to the median series, calculating whether two-time series are close depends on the scale of the median series.

 

Condition Type- Forecast: It forecasts the forthcoming performance of a metric and compares it to a fixed threshold. It is appropriate for metrics with robust trends or repetitive patterns. On the assessment of each alert, it predicts the future values of the metric along with the estimated deviation bounds. When any part of the bounds crosses the configured threshold, an alert is triggered.

Figure 43: Condition Type- Forecast

Trigger when the average/sum of every/maximum/minimum/at least one forecasted value of the metric is above/above or equal to/below/below or equal to the threshold in the next “X” interval.

  • Advanced option:
    • Evaluate the average forecasted value of the metric based on the “X” interval trend.
    • Check the condition at every one minute over rolling “X” intervals.
    • Check the condition at every “X” interval over a fixed “X” interval.
    • Severity: Critical / Major / Minor. (default is Major).
    • Apply default/simple/reactive model for Linear forecast.

OR

  • Apply hourly/daily/weekly choices for Seasonal forecasts.
  • Linear Forecast: It is used for metrics having fixed trends but no recurring seasonal pattern. Following are the models, which control this algorithm’s sensitivity to level shifts:
  • Default: Adjusts to the most recent trend and concludes data while being resistant to recent noise.
    • Simple: Performs a strong linear regression through the complete past.
    • Reactive: Concludes the latest performance at the risk of overfitting to noise, spikes, or dips.
  • Seasonal Forecast: This algorithm is used for metrics with recurring patterns. There are the following options:
  • Hourly: Behavior expectation of the same minute post hour like past minutes post hour. For example – 7:20 behaves like 6:20, 5:20, and so on.
  • Daily: Behavior expectation of the same time today like past days. For example, 7 pm today behaves like 7 pm yesterday, 7 pm the day before yesterday, etc.
  • Weekly: Behavior expectation of the mentioned day of the week like past days of the week. For example – this Thursday behaves like past Thursdays.

Trigger when every forecasted value of the metric is above/above or equal to/below/below or equal to the threshold in the next “X” interval.

  • Advanced option:
    • Evaluate the average forecasted value of the metric based on the “X” interval trend using last/any “Z” % samples.
    • Check the condition at every one minute over rolling “X” intervals.
    • Check the condition at every “X” interval over a fixed “X” interval.
    • Severity: Critical / Major / Minor (default is Major).
    • Apply default/simple/reactive model to make a linear/seasonal

 

Recovery Threshold: Recovery thresholds are optional thresholds added to alert conditions (Critical/ Major/Minor) to indicate an additional condition to metrics recovery from alert/warning states to normal states.

Example: If the critical threshold value is defined as 100 and the recovery threshold is defined as 50, then the recovery threshold is satisfied when the metric value is reached 50.

Alert Action

You can specify what actions to be taken when an event is generated. You can perform many operations at a single point of time as shown in Figure below.

Figure 44: Alert Action
  • Actions: To execute an action when an event is generated. You can select predefined actions (for example – Take Thread Dump, Take Heap Dump, Send Email) from the list or create a new action.
  • Send Notification to: To send the event notification to a particular email ID(s). Specify the email IDs in comma-separated format.
  • Forward Alert to: To send the event notification to an extension, such as Big Panda, Cisco Spark, Microsoft Kaizala, Microsoft Teams, PagerDuty, and Service Now.

Note: After the user has entered all the fields, they have to click on the Add Action button in order to add the selected action to the Action field.

 

Alert Description

You can specify an insight about the generated alerts.

Figure 45: Alert Description
  • Alert Message: The message to be displayed when an alert is generated. Example: Critical: High CPU Usage. You can also specify some variables here. Example: $SEVERITY: $PRODUCT_NAME $ALERT_TYPE Alert for one of the severely affected subjects. For more details, refer to the Add Action
  • Alert Description: The detailed description of the alert for more understanding and clarity. Example: A critical alert is generated because resource overhead is affecting the CPU performance. This needs to be fixed asap.

Recommendation: Preventive measures for improvement and overcome the reason for alert generation. Example: Release the unwanted resources to streamline the CPU performance.

Advance Settings

Here, you can specify some advanced level settings for the alert rule.

Figure 46: Advance Settings
  • Notify again, if alert remains in the same severity for more than or equal to minutes : To generate another notification after every specified interval to the user (as specified in the Actions section) if the generated alert remains in the same severity/continuous state (such as critical, major, minor) for more than the specified minutes.
  • Apply rule after minutes on new discovery of subject: To apply a delay (in minutes) on the triggering of a rule if a new subject is identified. This is helpful in cases when subjects get introduced at runtime and the initial data may take some time.
  • Configure Warning alert when no data available for any subject: To configure the generation of a warning alert if no data is available for a particular subject.
  • Configure Rule Schedule: To schedule this rule for a particular time duration. There are following options with which a user can configure the rule in this field which are listed below:
    • Every Day: The alert rule is triggered at the specified time each day. Example: If you select the time from 15:00 to 16:00, the rule is triggered at this time each day.
    • Every Week: The alert rule is triggered on the specified time of the selected day of a week. Example: If you select the time from 15:00 to 16:00 for Monday, the rule is triggered at this time each Monday.
  • Every Month: The alert rule is triggered at the specified time of either every particular day of the selected week or every selected day of the month.
    • Example – 1: If you select the time from 15:00 to 16:00 for the second Monday of the month, the rule is triggered on that time.
    • Example – 2: If you select the time from 15:00 to 16:00 every 15th day of the month, the rule is triggered on that particular time of the selected date.
  • Every Year: The alert rule is triggered on the specified time of either every particular day of the selected week of the month or every selected day of the month.
    • Example – 1: If you select the time from 15:00 to 16:00 each second Monday of March, the rule is triggered on that time.
    • Example – 2: If you select the time from 15:00 to 16:00 every 15th day of March, the rule is triggered on that time.
  • Custom: The alert rule is triggered on the specified date and time. For Example: If you select the time date and time from 15:00 18/05/2021 to 16:00 18/05/2021, the rule is triggered on that particular date and time.

 

  • Applicable tags on this rule are: To associate all the events with tags that are configured in rule. These tags are further used in different applications as per their needs.e.: Infra or Business.
  • Save with Rule Name: In this the alert will be save with the rule name mentioned.
  • Enable option: Enable option is required to configure the alert. If not enable, then configuration will not be done.

Alert Actions

These refer to the actions associated with an alert, which are executed on a certain trigger. Mainly alert actions are divided into the following categories:

  • Notification Actions like sending emails or SMS or sending SNMP Traps. Besides this, there are multiple extensions available to send notifications to third-party programs like ServiceNow, Cisco Spark, Slack, and PagerDuty.
  • Diagnostics actions like taking TCP Dump, Thread Dump, and Heap Dump.
  • Remediation action like running some custom scripts to restart a server/instance upon consuming high CPU/Memory.
  • And some advanced level alert actions.
Figure 47: Alert Actions

The following details are displayed:

  • Action Name: Name of the alert action.
  • Action Type: The action type configured for the action, such as sending email, taking thread dump, heap dump, TCP dump, or any other action.
  • Action: The action option is used to edit the action list.

You can perform the following operations:

  • Add alert action by clicking the Add Action
  • Refresh all the alert actions by clicking the button.
  • Copy the selected alert actions by clicking the button.
  • Delete the selected alert actions by clicking the  button.
  • Download the selected alert actions in Word, Excel, and PDF by clicking the button.
  • Import the selected alert actions by clicking the button.
  • Export the selected alert actions by clicking the button. 
  • Apply column filters by clicking the button.
  • View/hide columns by using the button. 
  • Edit an alert action by clicking the button in the Actions section.
  • Add alert history by clicking the Action History

Add Alert Action

You can add an alert action by clicking the Add Action button on the Alert Actions window as shown in Figure below.

Figure 48: Adding Alert Action

This displays the Add Actions window where you can add the alert actions.

Figure 49: Add Action

Specify the Action Name and provide the following details:

Notification

Here, you can specify what type of notification to be used to notify the user about the alert generation. This includes notifications via email, SMS, SNMP traps, and forwarding alerts to extensions.

Figure 50: Notification
  • Send an Email: To send notifications via email.
    • Generate Mail using Template: To generate the email using the Thyme leaf template.
    • Email Receiver: To provide the email addresses of the receivers.
    • Subject Mail: To mention the email subject. You can also use some predefined variables. Example: $SEVERITY: $PRODUCT_NAME $ALERT_TYPE Alert for one of the severely affected subjects.

Note: To add some predefined texts to the subject of mail, user can click on the ADD  button.

  • Pre Text: It is the text to be displayed at the beginning of the email body.
  • Post Text: It is the text to be displayed at the end of the email body.
  • Send an SMS Message: To send an alert notification via SMS. Type the phone number in the SMS Receiver to which the SMS message needs to be sent.
  • Send SNMP Traps: To configure Simple Network Management Protocol (SNMP) notification settings to notify users through SNMP traps when there is an alert generation.
Figure 51: Send SNMP Traps
  • Consolidated notification for a rule: To send a combined notification for a rule.
  • SNMP Server: The server used for sending notifications.
  • SNMP Port: An SNMP port is the SNMP communication endpoint. SNMP generally uses User Datagram Protocol (UDP) port number 161/162.
  • SNMP Version: There are three versions of SNMP: SNMPv1, SNMPv2c, and SNMPv3.
    • v1: The initial version of the protocol.
    • v2c: The revised version with enhanced protocol packet types, transport mappings, and MIB structure elements, but also uses the existing SNMPv1 administration structure (“community-based” and hence SNMPv2c)
    • v3: Facilitates remote configuration of SNMP entities. It also adds both encryption and authentication, which can be used together or separately, making this the most secure version yet.

Advanced Email Settings

Figure 52: Advanced Email Settings

Chart Configuration

  • Show charts in Email: Setting to show/hide charts in the notification email.
  • Specify the maximum number of charts, type of chart (line, bar, or area), and the duration of each graph (in minutes).
  • Specify the criteria to select chart metrics. You can choose only one from the following options:
    • Use metrics on which alerts are generated: To use only those metrics on which the alerts are generated, the rest metrics are ignored.
    • Identify and show more relevant metrics where similar patterns are matched: This criterion is used to apply the pattern match. Specify a catalogue, which contains the graphs information on which you can apply the pattern match. To apply pattern matching, you need one baseline with which you can compare all the graphs available in the catalogue. To get the baseline graph (for which the alert is generated), you need some criteria and it should have the minimum or maximum value across all the indices of one condition for which the alert is generated. Once the baseline is selected, you can compare each sample of both the graphs (baseline as well as the catalogue graphs) and filter all the graphs, which satisfy the threshold value given in the action. After that, you can send all the resultant graphs in the email body along with all the alert information.
    • Place all the metrics in separate charts: To place all the metrics in separate charts. When disabled, all the metrics are merged and displayed in a single chart.

Stats Report Configuration

You can view charts for the metrics on which an alert has been generated, as well you can also see the metrics, which are matching the same pattern as the alert metric, to find out some clue about the root cause. You can provide a maximum of 150 charts in an alert email and graph duration can be added up to 1440 minutes. If you try to provide inputs beyond the specified limits, an alert message is displayed on saving and does not allow saving the values. Whenever an alert is generated, a tabular report is sent in the alert email as a link and an attachment. This helps you to reduce manual processing time to analyze an alert. The report can also be generated by using a template.

Figure 53: Stats Report Configuration

It has following option:

  • Generate report and send link with mail: Enable this to send the link of the report generated with mail.
  • Select whether to include tabular, word, and HTML.
  • Select the time for which report needs to be generated.
  • Use metrics on which alerts are generated: To use only those metrics on which the alerts are generated, the rest metrics are ignored.
  • Use metrics from: Enable and from the dropdown select report from where metrics are to be used.

 

  • Forward Alerts to: To forward alert notifications to extensions. Extensions are groups of packages and classes that are bundled in a single jar and make it available to you when the need arises. Once configured, the notification begins flowing into the application and you can view the alert incidents in the application. Examples of applications – Big Panda, Cisco Spark, Microsoft Kaizala, Microsoft Teams, PagerDuty, Service Now, Slack, and Other Cavisson Products.

 

Figure 54: Forward Alerts to
  • NO_AUTH_NO_PRIV: Authentication protocol and Privacy are protocols not required. On selecting this, specify the username.
  • AUTH_NO_PRIV: Authentication protocol required, but Privacy Protocol not required. On selecting this, specify the username, select the authentication protocol, and provide the authentication password.
  • AUTH_PRIV: Both Authentication protocol and Privacy protocol are required. On selecting this, specify the username, select the authentication protocol, and specify the authentication password. Also, select the privacy protocol, and provide the password.

Forward Alerts to a Central Dashboard (Other Cavisson Product)

This feature enables the forwarding of the alerts from one Cavisson product to another Cavisson product, so that all the alerts are visible on one central dashboard. This is useful in the scenarios where you want to see multiple products’ alerts in a single dashboard. For example: In one environment there are multiple Cavisson products configured, let’s say NetVision (NV) and NetDiagnostics (NDE) and there is a requirement of sending all NV alerts automatically to NDE so that all the alerts generated from both the products are visible at one place. This feature enables:

  • Alert integration added for sending alerts to other Cavisson product(s).
  • Sending alerts from multiple products to a single Dashboard (many to one).

Forward Alert to Slack

You can also send notifications to the Slack tool. Once the Alert Action is configured using the Slack extension to send a notification, the notification begins flowing into the Slack application. You can see the alert incidents in the Slack application.

Figure 55: Forward Alert to Slack

Forward Alert to Big Panda

You can also send notifications to the Big Panda tool. Once the Alert Action is configured using the Big Panda extension to send a notification, the notification begins flowing into the Big Panda application. You can see the alert incidents in the Big Panda application.

Figure 56: Big Panda Alert Window

Forward Alert to Microsoft Teams

Microsoft Teams is a unified communication and collaboration platform that combines persistent workplace chat, video meetings, file storage, and application integration. Support is provided to send notifications from the alert engine to Microsoft Teams using the alert extension.

You can also send notifications to the Microsoft Teams tool. Once the Alert Action is configured using the Microsoft Teams extension to send a notification, the notification begins flowing into the Microsoft application. You can see the alert incidents in the Microsoft Teams application.

Figure 57: Microsoft Teams Alert Window

Forward Alert to Microsoft Kaizala

Microsoft Kaizala is a secure messaging and works management software application for collaboration among users inside and outside of organizations, including the ability to send and receive instant messages, coordinate tasks, and submit invoices.

You can also send notifications to the Microsoft Kaizala tool. Once the Alert Action is configured using the Microsoft Kaizala extension to send the notification, the notification begins flowing into the Microsoft Kaizala application. You can see the alert incidents in the Microsoft Kaizala application.

Figure 58: Microsoft Kaizala Alert Window

Diagnostics

You can also specify what diagnostics actions are to be triggered on the alert generation.

Figure 59: Diagnostics
  • Take a Thread Dump: To take a snapshot of the state of all the threads of a Java process. The user has to specify the values in the following fields:
  1. Number of thread dumps along with the interval – User can set a timeout (in minutes) for taking a thread dump within the provided field.
  2. Max Time for Taking Thread Dump in Minute(s) – User can set maximum time (in minutes) for taking a thread dump within the provided field.
  • Take Heap Dump: To take a snapshot of all the objects that are in memory in the JVM at a certain moment. The user has to specify the values in the following fields:
  1. Number of heap dumps along with the interval – User can set a timeout (in minutes) for taking a thread dump within the provided field.
  2. Max Time for Taking Heap Dump in Minute(s) – User can set maximum time (in minutes) for taking a thread dump within the provided field.
  • Take a TCP Dump: To take a snapshot of network traffic going through your system. The user has to specify the values in the following fields:
  1. Interface
  2. Max Duration (sec)
  3. Size (MB)
  4. Number of Packets
  5. Port
  6. Additional Attributes (If required).
  • CPU Profiling: To take a snapshot of what functions consume what percent of CPU time. Specify the duration in seconds. Here, the user has to provide the duration time in Seconds (s).
  • Java Flight Recording: To allow Java administrators and developers to gather detailed low-level information about how the Java Virtual Machine (JVM) and the Java application are behaving. The user has to specify the values in the following field which is listed below:
  • JFR would be Initiated for, and Saved At, and Waiting Time: This field is used for specifying the Java Flight Recorder’s time duration, the path on which it is saved and the waiting time of the process.
  • Select Pattern: In this field, the user has to select the pattern in which the thread dump and heap dump will be taken.

 

Remediation

These are actions like running some custom scripts to restart a server/instance upon consuming high CPU/Memory.

Figure 60: Remediation Window
  • Run a script executable on problematic Nodes:
  • To run a script or an .exe file on problematic nodes.
  • The user has to provide the Script Name.
  • To run this on the server, turn on the Run-on Server toggle key.

Advanced Configuration

This feature is used for sending locations in: Alert Mail, SNMP Trap, and Cisco Spark. Regex is used to extract locations from Alert vectors.

Figure 61: Advance Configuration Window
  • Pattern to fetch Subject Identifier ($SUBJECT_ID):

$SUBJECT_ID defines indices identifier i.e. unique substring of a vector. You can provide regular expressions to fetch a unique substring from every vector. This helps you to identify every vector uniquely.

 

Use cases for $SUBJECT_ID:

  • You can provide $SUBJECT_ID in the subject, pre-text, and post-text of an Email.
  • You can provide $SUBJECT_ID in the message of the rule for the SNMP trap.
  • You can provide $SUBJECT_ID in the message field of the rule for Alert-Extension.
    Note: If you use any of the above use cases then $SUBJECT_ID is replaced by such substring from the vector which is the outcome of the given regular expression after compilation on that vector.

 

Example: 1

If you have provided regular-expression “[0-9]{3}$”

And the alert got triggered in the vector “AppTier>Server000703”

And you have given $SUBJECT_ID in the subject of the email

Then, in the subject of the email, “703” is displayed instead of $SUBJECT_ID

 

Example: 2

If you have provided regular-expression “(? <=>h121580vaps) \d+”

An alert got triggered in the vector “ATG-OPEN-API-REST-BURST>h121580vaps2360>kls-rest-43”

And you have given $SUBJECT_ID in the subject of the email

Then, in the subject of the email, “2360” is displayed instead of $SUBJECT_ID

  • Test the above indices identifier pattern on: You can test the provided indices identifier by using the Test button.
  • Provide a favorite link in place of $FAV_LINK: The actual favorite link is added in the email. You can directly view that favorite in the Dashboard by clicking the favorite link. In addition, you can open favorite metrics with graph time including the provided (±) minute(s) and time window given in the rule.
  • Place all the metrics in a separate widget: On enabling this toggle button, all the metrics are placed in separate widgets.

Note: After the user has entered all the fields, the user can Save the configurations, in order to save the user has to click on the Save  button. If a user wants to exit the window, they can click on the Cancel button.

View Alert Action History

Alert history is useful in obtaining insights into past-generated alerts and to understand how the severity of the specific alerts may have changed over a period of time. The details displayed are – Status, Rule Name, Action Time, Action Type, and Description.

Figure 62: Alert Action History Window
  • Preset: It is the duration to which you want the alert history to be generated. There are various options, such as – Last 10 minutes, last 1 hour, today, yesterday, last 7 days, this week, last 3 weeks, last 6 months, last year, custom. In case of custom, provide the start date and time and end date and time.
  • Search: To search for an alert from the alert history table.
  • Download: To download the alert history in word, excel, and PDF formats.
  • Toggle Columns: To show/hide columns in the table.
Previous